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FINAL  REPORT 

CONTRACT  No.  DAAH04-96-C-0075 


1.0  OBJECTIVES 

UTRS  proposed  to  develop  a  Computer  Aided  Medical  Assistant  (CAMA)  system 

in  response  to  Topic  Number!  Army  96T004  -  Computer  Aided  Diagnosis  and  Treatment 

Display.  The  Phase  I  CAMA  system  sought  to  accomplish  the  following  objectives: 

•  Research  and  design  a  mobile,  hardware  and  software  diagnostic  system  that  would  be 
unobtrusive  and  efficacious  for  a  field  medic  under  battlefield  conditions; 

•  Research  and  develop  a  voice  recognition  application  that  would  allow  the  user  to 
diagnose  a  patient  in  a  hands  fi-ee  environment; 

•  Research,  design,  and  develop  an  electronic  breadboard  (EB)  capable  of  interfacing  to 
non-invasive  sensors; 

•  Research  and  integrate  two  non-invasive  sensors  into  the  EB  that  would,  in  turn, 
interface  with  the  CAMA  system; 

•  Research  head  mounted  display  (HMD)  technology  that  would  effectively  display 
pertinent  data  under  field  conditions; 

•  Integrate  and  test  all  of  the  above  into  a  self-contained,  mobile,  CAMA  system. 


2.0  ACCOMPLISHMENTS 

2. 1  A  Mobile  Hardware  and  Software  Diagnostic  System 

UTRS  proposed  to  use  The  Wearable™  as  our  hardware  platform.  The 
Wearable™  is  a  flexible  2  lb.,  486-based,  75MHz,  computer  that  is  worn  like  a  belt.  It  is 
equipped  with  4  PCMCIA  (PC  Card)  slots,  24MB  RAM,  340MB  disk  space  (via  PC  Card 
[510  MB  optional]),  and  numerous  other  amenities  that  make  it  an  excellent  choice  for 
field  operations.  The  Wearable™  operates  under  the  Windows  3.x  or  Windows95 
operating  system  (our  version  uses  Windows95). 

Prior  to  our  proposal  for  this  effort,  UTRS  was  already  a  value-added  reseller 
(VAR)  for  The  Wearable™;  as  such  we  already  owned  a  unit  and  did  not  use  STTR  funds 
to  purchase  one  under  this  contract.  During  the  course  of  this  effort,  we  did  make 
suggestions  to  the  manufacturer  (Computing  Devices  International)  for  product  design 
improvements  that  would  enhance  its  adaptability  and  survivability  under  field  conditions. 
Several  of  these  recommendations  were  incorporated  in  the  latest  release  of  the  product, 
including; 

•  A  modular,  hardened  shell  for  improved  durability; 

•  An  improved  BIOS  that  supports  “hot  swapping”  of  batteries; 

•  A  68  pin  interface  connector  for  improved  configuration  of  peripherals; 


1 


An  exterior  on/ofF  switch  and  LED  indicator. 


In  addition,  a  new  version  that  incorporates  a  Pentium-class  processor  has  been 
scheduled  for  release  in  lQtr97. 

With  the  hardware  platform  chosen,  we  focused  our  efforts  on  the  following  five 
research  areas:  the  CAMA  application;  the  voice  interface  module;  the  design  and 
fabrication  of  the  electronic  breadboard  (EB);  research  of  appropriate  non-invasive 
sensors  that  could  be  interfaced  with  the  EB;  and  research  for  an  appropriate  display 
device. 

2.2  CAMA  Application 
2.2.1  Research 

Prior  to  developing  the  CAMA  graphical  user  interface  (GUI),  UTRS  spoke  with 
many  potential  users,  including  army  and  civilian  medical  personnel,  doctors,  nurses,  and 
clinicians.  The  most  dominant,  recurring  feedback  was  to  keep  the  presentation  of  screen 
information  to  a  minimum.  Especially  under  field  (or  battlefield)  conditions,  where  the 
user  will  be  experiencing  elevated  levels  of  stress,  and  auditory  and  visual  stimulation,  a 
complex  GUI  could  hinder  rather  than  aid  the  user. 

In  the  proposal  for  this  effort,  we  had  intended  to  create  a  database  of  information 
that  would  contain  biographical  data  for  sample  patients.  This  information  would  include 
a  soldier’s  benchmarked  vital  signs  to  be  used  as  comparison  for  later  test  information. 
Under  a  field  scenario,  a  medic  would  enter  the  downed  soldier’s  dogtag  number  (via 
voice,  barcode,  etc.)  and  the  database  would  retrieve  the  soldier’s  stored  medical  profile. 
The  profile  would  display  the  benchmarked  profile  as  well  as  pertinent  medical  information 
regarding  the  soldier’s  health  conditions,  such  as  allergies  to  certain  medicines,  etc.  The 
medic  would  then  enter  the  current  vital  'sign  information  via  voice,  integrated  non- 
invasive  sensor,  pen,  or  traditional  method  (keystroke,  mouse).  The  intention  being  that 
the  new  information  could  be  compared  to  the  patient  s  benchmark  to  facilitate  an 
intelligent  diagnosis. 

In  our  interviews  however,  military  medical  personnel  suggested  that  this  effort, 
although  valuable,  is  not  of  paramount  importance  in  the  field,  primarily  because  a  fieW 
medic  does  not  have  sufficient  time  to  perform  these  procedures.  Other,  more  basic 
priorities  were  suggested.  For  example,  a  more  important  module  would  be  one  that 
reminds  the  medic  to  remember  his  A,  B,  Cs  (airway,  breathing,  circulation).  In  times  of 
stress,  a  medic  may  be  so  consumed  with  administering  to  a  blatant  affliction  (e.g. 
stanching  the  flow  of  blood  from  a  wound),  that  he  overlooks  a  more  critical  emergency 
such  as  a  blocked  airway. 

These  (and  other)  valuable  suggestions  contributed  to  the  prototype  CAMA  GUI 
and  functionality. 
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2.2. 1  Work  Carried  Out 


The  CAMA  application  was  written  in  the  Microsoft  (MS)  VisualC-H-  v4.2 
programming  language  and  its  dialog  editor.  It  is  integrated  with  the  Lernout  &  Hauspie 
(L&H)  Voice  Recognition  Product  (VRP)  via  a  speech  recognition  Application 
Programming  Interface  (API)  that  interfaces  with  a  UTRS-developed  Dynamic  Linked 
Library  (DLL).  Our  DLL  is  written  in  pure  C.  The  application  resides  on  the  desktop  and 
is  activated  by  clicking  on  the  CAMA  icon.  An  introduction  is  presented  in  text, 
accompanied  by  voice  narration.  Each  paragraph  is  highlighted  as  the  speaker  narrates  the 
introduction.  The  brief  introduction  explains  the  objective  of  the  CAMiA  application  and 
instructs  the  user  to  try  it.  At  this  point,  the  user  can  activate  the  program  and  navigate 
through  the  application  solely  by  voice,  or  by  voice,  mouse,  and/or  keyboard. 


2.2. 1.1  Main  Menu 


The  user  is  presented  with  a  main  menu  as  shown  in  Figure  2.2. 1.1-1.  From  this 
screen,  he  can  choose  from  the  following  options: 


Selectldit 

•  Patient  Roster 

•  GPS 

•  Libraries 

•  Help 

•  S.O.P. 

•  Vital  Signs 

•  Patient  Data 

•  Exit 


Result 

Alphabetical  listing  of  recently  administered  patients 
Activates  GPS  Module 
Reserved  for  Medical  Library  Module 
Reserved  for  Help  Menu 

Activates  Standard  Operating  Procedures  Module 
Activates  Interactive  Vital  Signs  Module 
Alphabetical  listing  of  recently  taken  vital  statistics 
Exits  CAMA  system 


2.2. 1 .2  Patient  Roster 

The  Patient  Roster  window  is  shown  in  Figure  2.2. 1.2-1.  This  module  contains  an 
alphabetical  listing  of  patients  that  have  recently  been  under  the  medic’s  care.  The  medic 
can  tell  CAMA  the  name  of  the  listed  patient  and  CAMA  will  retrieve  the  most  recent 
medical  information.  To  navigate,  the  user  can  say  “down”  or  “up”  to  move  the  cursor 
one  patient  at  a  time,  or  “page  down”  or  “page  up”  for  the  cursor  to  move  one  page  at  a 
time. 
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Figure  2.2. 1 . 1-1  CAMA  Main  Menu 
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2.2.1.3 


GPS 


The  Global  Positioning  System  (GPS)  window  is  shown  in  Figure  2.2. 1.3-1.  The 
GPS  Module  activates  the  onboard  Trimble  Navigation  GPS  PC  Card.  GPS  coordinates 
are  taken  by  the  Card  which  is  tethered  to  a  miniature  antenna.  The  initial  fix  requires 
approximately  ten  (10)  minutes  and  due  to  the  inherent  weakness  of  GPS  signals,  the 
antenna  must  be  located  outdoors  to  be  operational.  A  recent,  improved  release  of  this 
card  allows  for  rapid  data  acquisition  after  the  initial  fix  has  been  taken,  or  if  the  receiver 
has  been  initialized  with  pertinent  geographical  data. 


Latitude  (Dag,  Min)  Deia 


Longlluda  (Dag,  Min)  |Na  O  dts 


AtStuda  p:  HAE)  |No 


TEmeCGMT)  NaDatef 


iNoDatet 


2.2. 1.3-1  GPS  Module 


2.2. 1.4  Libraries 

The  Libraries  Module  is  not  yet  implemented.  When  activated  from  the  main 
menu,  a  screen  informs  the  user  that  it  is  currently  unavailable.  This  module  will  contain 
medical  protocols,  drug  dosages,  and  other  academic  information. 

2.2. 1.5  Help 

The  Help  Module  is  not  yet  implemented.  This  module  will  contain  general 
CAMA  information  as  well  as  pertinent  “how  to”  information  to  aid  in  the  use  of  the 
CAMA  system. 
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2.2. 1.6  Standard  Operating  Procedures 

The  SOP  window  is  shown  in  Figure  2.2. 1 .6-1. 


Ernergencjii  Medical  T 


Open  the  Airway 


Upper Ofosimdion 


Pejiorm  Rescare  Sr@fefj:inf 


Aritniftii^ef  Extemai  Che#  Cot^ipre^sjon 


immolJilKe  a  Suspected  Disiecated^Fraclyred  Ankle 


Apply  f%u«asicSpint  to  Suspected  Fractoe 


tvlsin  ye^u 


Figure  2.2. 1.6-1  SOP  Module 

The  SOP  is  currently  a  shell  window.  When  activated  from  the  main  menu,  the 
SOP  module  displays  the  above  information.  Time  constraints  precluded  us  from 
implemented  full  usage.  This  module  will  eventually  be  a  hypertext-enabled  module  that 
will  respond  to  the  user’s  voice  and  display  emergency  medical  treatment  options  for 
several  afflictions.  Currently,  when  the  user  says  “airway”  CAMA  presents  a  window  that 
informs  the  user  that  this  module  is  not  yet  implemented.  Under  a  subsequent  effort,  this 
request  would  present  stored  medical  treatment  procedures  matching  the  valid  syntax, 
e.g..  Opening  Airways,  or  Clearing  An  Upper  Arwav  Obstruction.  Where  applicable,  the 
procedures  will  have  additional  hypertexed  words  that  the  user  could  enunciate  to  take 
him  to  related  topics. 


2.2. 1.7  Vital  Signs 

The  Vital  Signs  window  is  shown  in  Figure  2. 2. 1.7-1.  This  date-  and  time- 
stamped  module  is  integrated  to  the  non-invasive  sensors  and  displays  the  parsed  data  in 
the  appropriate  fields.  In  addition,  the  user  can  enter  limited  information  in  the  Blood 
Pressure  and  Skin  Color  fields.  To  enter  information  in  the  Blood  Pressure  field,  the  user 
says  “Blood  Pressure”  and  the  cursor  will  appear  in  the  BP  box.  The  user  would  say  for 
example  “one  eight  zero  over  seven  eight”  to  enter  180/78  in  the  blood  pressure  field.  If 


an  error  is  made,  the  user  can  tell  the  computer  to  back  up  by  saying  “back”.  The 
complexion  state  is  a  check-box  field  and  the  user  merely  says  “normal”,  “pale”,  or 
“jaundiced”  for  a  check  to  appear  in  the  appropriate  area. 

Once  completed,  the  user  can  say  “record”  to  save  the  data,  or  “main  menu”  to 
return  to  the  main  menu. 


Figure  2.2. 1.7-1  Vital  Signs  Module 


2.2. 1.8  Patient  Data 

The  Patient  Data  window  is  shown  in  Figure  2.2. 1.8-1.  This  module  is  an 
alphabetical-oriented  window  that  displays  recent  test  results.  Patient  data  is  listed  as 
follows: 

J^atse  Date  Time  Temp  SP02  Hemt  BP  Ccsmpiexioa. 

Franklin,  Benjamin  Feb05,1997  0920  CE-12  20%  66  120:84  P 

Note:  Temperature  appears  as  “CE-12”  because  the  sensor  was  not  plugged  into  the 
system  at  the  time  the  data  was  recorded. 


The  user  can  return  to  the  main  menu  by  saying  “ok”. 


2.3  Voice  Recognition  Module 


2.3.1  Research 

UTRS  researched  the  following  voice  recognition  products  (VRPs); 

•  Dragon  Dictate  -  Power  Edition 

•  IBM  -  Voice  Type  Application  Factory 

•  Kurzweil  Applied  Intelligence  -  VOICE 

•  Lemout  &  Hauspie  Speech  Products  -  asrl  500,/M 

Our  research  into  the  above  VRPs  was  not  all  encompassing.  What  we  were 
searching  for  was  a  product  that  would  satisfy  our  criteria  to  demonstrate  the  feasibility 
and  functionality  of  the  proposed  CAMA  system.  Our  VRP  checklist  included  the 
following  criteria: 

•  Voice  Recognition  Accuracy 

•  Voice  Recognition  Type  (Command  &  Control  versus  Dictation) 

•  Voice  Synthesis  Capability 

•  Speaker  Independence 

•  Application  Specific  Contexts  and  Dictionaries 

•  Price 


Some  of  the  features  of  these  VRPs  have  changed  since  the  start  of  this  effort, 
however,  at  the  time  we  were  researching  these  products,  they  retained  the  following 
qualities; 


Dragon 

IBM 

Kurzweii 

L&H 

Accuracy  >  ■ 

Satisfactory 

Satisfactory 

Satisfactory 

Satisfactory 

Type 

Dictation 

Command/Ctrl 

Dictation 

Command/Ctrl 

Synthesis  . . 

No 

No 

No 

Yes 

Speaker Ind. 

Yes 

Yes 

Yes 

Yes 

Context  s/Dict. 

Yes 

Yes 

Yes 

Yes 

Price 

$1,700 

$1,000 

$595 

$590 

“Satisfactory  accuracy”  was  defined  as  80%  or  better  “out  of  the  box”.  Due  to 
time  constraints,  we  were  also  looking  for  a  VRP  that  retained  the  following  subjective 
characteristics; 

•  A  short  idiosyncratic  learning  curve; 

•  Rapid  prototyping  and  integration  capability; 

•  Available  customer  support; 

•  Customization  capability  that  did  not  require  OEM  intervention. 
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After  reviewing  the  specifications  for  each  VRP,  we  conducted  voice  interviews 
with  each  vendor,  ultimately  deciding  to  purchase  the  L&H  VRP.  In  addition  to  cost, 
L&H  offered  voice  synthesis  capabilities  (text  to  speech),  a  Command  and  Control 
methodology,  and  an  innovative  Lextool  Vocabulary  Builder  that  allowed  us  to  add 
vocabularies  to  our  speech  recognition  application  via  keyboard  entry  or  text-file 
download. 

2.3.2  Work  Carried  Out 

The  L&H  asr 1500/M  Automatic  Speech  Recognition  (ASR)  Software 
Development  Kit  (SDK)  is  a  phonetic  speech  recognition  search  engine  with  optimization 
for  commonly  used  words.  The  SDK  enabled  us  to  utilize  C/C++,  Visual  Basic,  and  other 
programming  languages  to  incorporate  speech  recognition  functionality  into  our  CAMA 
application  under  the  Windows95  operating  system. 

L&H  uses  a  callback  method  of  notification  when  sound  occurs.  That  is,  one  tells 
a  routine  in  the  L&H-supplied  DLL  what  routine  in  the  CAMA  software  it  should  call. 
When  that  routine  is  called,  it  assimilates  the  information  and  responds  with  the 
appropriate  action.  Of  course,  the  callback  routine  needs  to  know  something  about  what 
is  going  on  in  the  CAMA  application,  i.e.,  where  the  user  is,  and  what  the  valid  responses 
are. 

We  created  our  own  DLL  (Inhdll)- contains  the  callback  routine  and  utilities 
that  the  CAMA  application  must  call  to  control  the  callback  routine.  The  callback  routine 
responds  when  it  recognizes  a  particular  word.  For  example,  when  the  CAMA  application 
displays  a  dialog  box  with  yes  and  no  buttons,  just  prior  to  displaying  the  box  it  calls  a 
routine  in  our  Inhdll  to  indicate  that  the  words  yes  and  no  should  be  recognized.  When  it 
recognizes  a  valid  response,  the  callback  routine  activates  the  appropriate  Windows95 
command  as  if  the  user  had  clicked  the  mouse  in  the  yes  or,  if  appropriate,  the  no  button. 
When  the  dialog  box  is  to  be  removed  from  the  screen,  these  links  between  speech  and 
Windows  action  must  also  be  removed,  so  a  routine  is  provided  in  the  Inhdll  to  remove 
the  link. 

2. 3 .2. 1  Auxiliary  Work  Carried  Out 

UTRS  had  been  selected  as  a  beta  developer  for  the  IBM  VoiceType3  VRP  many 
months  before  the  start  of  this  STTR  effort,  IBM’s  previous  product.  Voice  Type 
Application  Factory  (VTAF)  was  scheduled  to  be  discontinued  without  subsequent 
support.  VoiCeType3  was  being  marketed  as  a  hybrid  VRP  that  combined  dictation  and 
command  and  control  functionality.  It  was  scheduled  to  be  released  around  the  time  of 
this  STTR.  However,  upon  its  release  and  its  subsequent  shipment  to  our  office,  we 
discovered  substantial  software  anomalies  that  precluded  further  use  until  the  bugs  were 
rectified  by  the  manufacturer.  By  the  time  the  rectified  version  was  released,  we  were  four 
months  into  the  STTR  and  time  constraints  precluded  the  option  of  using  the  new  VRP. 
However,  after  developing  the  CAMA  application  using  the  L&H  VRP  and  integrating  it 
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into  the  C-H-  screens,  we  decided  to  devote  some  time  with  the  IBM  product  integrated 
into  Delphi  screens. 

2.3.3  Results  Obtained 

We  were  able  to  use  the  L&H  SDK  to  adequately  demonstrate  the  CAMA 
application  with  passable  accuracy;  however,  the  speech  recognition  engine  did  not  always 
operate  in  a  consistent  manner.  For  example,  speech  recognition  was  excellent  one  day 
and  poor  the  next  (under  identical  external  environments).  Thresholds  and  input  gains 
were  kept  at  the  same  levels,  and  peripherals  (e.g.  microphone  and  speakers)  and  testing 
environment  were  unchanged.  We  concluded  that  the  user  s  speech  pattern  (i.e.  volume 
and/or  articulation)  in  conjunction  to  the  placement  of  the  microphone  (i.e.  the  distance 
from  the  user’s  mouth  to  the  microphone  and/or  the  angle  of  placement)  were  the 
determining  factor(s). 

The  L&H  SDK  is  32  bit  code  which  enables  it  to  run  efficiently.  And,  as  part  of 
the  CAMA  appUcation,  we  intended  to  integrate  a  Global  Positioning  System  (GPS)  PC 
Card  into  the  system  to  enable  field  personnel  to  take  a  fix  on  their  location.  However, 
the  GPS  Application  Programming  Interface  (API)  was  written  in  16  bit  code.  Since  the 
two  APIs  could  not  communicate  with  each  other,  it  was  necessary  to  write  a  thunking 
layer  that  allowed  the  32  bit  application  to  communicate  with  the  16  bit  application.  The 
thunk  is  written  in  thunk  script  and  interpreted  by  a  thunk  compiler.  The  output  of  the 
thunk  compiler  (which  is  part  of  a  large  tool  package  sold  by  Microsoft)  is  assembly 
language  source  code  which  is  subsequently  assembled  and  linked  in  the  usual  fashion. 
Although  not  a  simple  feat,  the  thunking  layer  proved  successful  and  the  GPS  application 
can  now  be  activated  via  voice. 

An  impediment  to  simple  interaction  with  the  application  is  found  when  the 
application  plays  a  wave  file.  The  L&H  speech  engine  controls  the  audio  output,  therefore 
when  the  application  calls  a  wave  file,  the  engine  must  be  disabled,  and  then  re-enabled 
when  the  wave  file  finishes.  This  precludes  permitting  the  user  to  proceed  without 
listening  to  the  entire  wave  file. 


2.4  Electronic  Breadboard  (EB) 

2.4.1  Research 

In  order  for  the  non-invasive  sensors  to  interface  to  The  Wearable^*  (or  any 
handheld,  laptop,  or  portable  computer)  it  was  necessary  to  develop  an  interface  device. 
At  the  outset  of  this  effort,  we  proposed  to  design  and  develop  a  generic  interface  adapter 
that  would  function  through  the  use  of  a  PC  card.  (Initially  we  included  a  caveat  that  it 
would  probably  not  be  portable  under  a  Phase  I  research  effort.) 

The  objective  of  the  EB  was  to  enable  portable  computers  with  PC  slots  to  be  able 
to  function  as  vital  signs  computers.  Currently,  many  medical  product  companies  such  as 


IVAC,  Datascope,  and  Nellcore  manufacture  proprietary  devices  that  measure  heart  rate, 
blood  pressure,  temperature,  etc.  Our  objective  was  to  develop  an  electronic  breadboard 
that  would  take  analog  signals  from  these  devices  and  convert  their  data  to  digital  signals. 
The  EB  would  in  turn,  parse  the  digital  vital  sign  information  into  the  Vital  Sign  module  of 
the  CAMA  system.  It  would  be  accomplished  by  writing  a  dynamic  linked  library  (DLL) 
which  provides  the  common  interface  from  which  most  programming  languages  can 
interface. 

In  order  to  design  a  dynamically  configurable  interface  to  a  suite  of  medical 
sensors,  several  options  were  considered.  Based  on  size  constraints  and  ease  of  use  in  the 
field,  a  Type  II  PC  Card  was  selected  as  the  best  option  to  meet  design  criteria.  PC  Cards 
allow  plug  and  play  type  hardware  under  the  Windows  ’95  operating  system.  This  is 
realized  through  structured  abstraction  layers  defined  by  the  PCMCIA  2.0  standards 
(Socket  Services,  Card  Services,  Client  Device  Drivers).  Additional  abstraction  is 
provided  by  the  ’95  environment  (Configuration  Manager  functions.  Bus  Enumerator, 
Virtual  Device  Drivers).  Prototyping  PC  cards  are  commercially  available  and  also  reduce 
NRE  costs  and  development  time. 

Research  into  circuit  logic  design  was  performed  in  order  to  produce  an  interface 
card  which  could  be  reconfigurable  in  the  field  and  provide  the  required  functionality.  It 
was  essential  that  the  prototype  be  generic  in  design  such  that  it  would  be  capable  of 
interfacing  with  a  variety  of  sensors.  The  solution  to  this  requirement  was  a 
programmable  logic  circuit  which  could  be  downloaded  dynamically  in  the  field.  This 
gave  us  the  flexibility  necessary  to  design  the  prototype. 


2.4.2  Work  Carried  Out 

UTRS  designed  the  hardware/software  and  electronic  specifications  for  the  EB  and 
submitted  them  to  our  subcontractor.  New  Mexico  State  University’s  Physical  Science 
Laboratory  (NMSU  PSL).  PSL  performed  the  technical  research  required  to  fabricate  the 
EB.  PSL  ordered  the  requisite  materials,  staffed  the  production  team,  fabricated  the  EB, 
and  remained  in  close  communication  with  UTRS  during  the  contract  to  discuss  priorities, 
design  trade-oflfs,  and  technical  updates. 

2.4.2. 1  Elardware 

The  architecture  of  the  EB  consists  of  two  Application  Specific  Integrated  Chip 
(ASIC)  devices  and  tri-state  buffers  for  addressing  of  the  card.  It  uses  six  Analog  to 
Digital  (A/D)  converters  with  12  bits  of  resolution.  The  cabling  is  a  standard  tri-cable 
pigtail  which  is  connected  to  the  header  of  the  PC  Card.  The  hardware  design  was  driven 
by  the  fact  that  a  portion  of  the  control  logic  would  need  to  be  dynamic.  An  Altera  ELPD 
was  selected  to  provide  this  capability.  The  device  drivers  load  chip  logic  after  the  card  is 
inserted  and  identified  by  the  system.  The  hardware  consists  of  the  following: 


•  Accurite  HeadstartCard  prototyping  card 

•  Altera  EPF8282 ATC 1 00-3  EPLD 

•  Maxium  MAXI  96 ACAI  1 2-bit  DAS 

•  74HC 1 3  8M  3  to  8  line  decoder  IC 

•  74HC574WM  octal  D  flip-flop  IC 

74HC138  and  74HC574  are  used  to  load  the  Altera  Electronically  Programmable 
Logic  Device  (EPLD)  via  an  I/O  port  from  the  Zilog  interface  IC  on  the  HeadstartCard. 
A  portion  of  the  EPLD  is  SRAM  based  and  must  be  loaded  after  power  is  applied.  The 
EPLD  controls  the  DAS  and  interfaces  the  DAS  data  to  the  PC-CARD  interface.  The 
MAX196,  is  a  multirange,  single  +5  volt,  12  bit  DAS  with  a  12-bit  bus  interface.  There 
are  six  (6)  analog  input  channels.  Only  three  (3)  are  used  in  this  application.  Each  analog 
input  has  software  selectable  input  ranges  of  ±10  volts,  ±5  volts,  0  to  +10  volts  and  0  to 
+5  volts.  The  CAMA  application  uses  0  to  +5  volts. 

Interface  to  the  sensor  suite  is  through  a  3-gang  connector  interface.  This 
interface  provides  auto  identification  of  the  attached  sensors  produced  by  pull-up  resistors 
in  the  sensor  interface  gang  (4  per  port)  and  a  sensor-unique  line  resistor  in  the  sensor 
headshell. 

2.4.2. 2  Software 

The  software  design  consists  of  a  device  driver  and  application-specific  software 
development.  The  system  had  to  recognize  the  interface,  dynamically  configure  to  it, 
recognize  the  attached  sensor,  and  provide  a  simple  interface  for  application  programs  to 
retrieve  sensor  data.  For  this  effort,  we  decided  to  make  the  application/driver  interface 
polled  rather  than  interrupt  driven  so  that  the  sensor  subsystem  would  not  use  an 
excessive  amount  of  system  resources. 

The  Altera  EPLD  is  programmed  during  the  first  call  to  the  PCMCIA  card  by  an 
application  program.  The  driver  determines  if  the  Altera’ s  setup  has  been  modified  since 
the  last  insertion;  if  not,  it  downloads  the  TTF  file  through  the  Zilog  chip  set  into  the 
Altera.  Since  the  tuple  (data  structure  used  to  describe  the  PC  Card  functionality) 
information  permits  multiple  card  configurations,  dynamic  loading  functionality  is  inherent 
in  the  card  design.  Currently  the  card  configuration  tuple  describes  the  card  as  both  an  10 
port  and  as  a  memory  port.  The  device  driver  uses  the  10  port  as  the  prototype  version 
contains  no  on-board  memory  (the  device  pseudo-registers  are  flip-flop  groups  on  the 
EPLD). 


The  device  load  code  is  contained  in  the  Altera  Setup  module  in  the  device  driver. 
This  software  emulates  the  required  Altera  signal  conventions  and  timing.  It  drives  the 
clock,  data  lines,  etc.  Once  the  EPLD  is  set,  the  system  operates  in  a  normal  manner. 

The  CAMA  PC  Card  is  designed  to  sample  each  of  three  possible  separate 
instruments  via  the  Altera  Analog  to  Digital  channels.  Each  instrument’s  connector  is 
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keyed  with  an  instrument  code  that  is  passed  along  with  the  sample  by  using  4  data  bits 
(the  sample  is  collected  from  a  12  bit  A/D  and  we  used  the  other  4  bits  of  the  16  bit 
register  to  ID  the  instrument).  When  the  connector  is  plugged  into  the  CAMA  PC  Card, 
the  A  to  D  samples  the  instrument  code  and  data  values.  The  driver  reads  these  values, 
parses  the  code  and  value  portions  for  each  of  three  channels  and  returns  this  data  to  the 
Win32  application  which  called  the  virtual  device  driver. 

2.4.3  Results  Obtained 

The  sensor  subsystem  successfully  obtained  thermister  data  and  auto  identified 
pulse/oximetry  sensors.  It  was  integrated  into  the  CAMA  system  and  provides  a  basis  to 
continue  development  of  a  more  robust,  fully  automated  medical  field  system. 

The  prototype  card  and  associated  software  were  tested  in  continuous  sample 
mode  over  a  72  hour  period  without  failure.  Several  hundred  sensor  connect/disconnects 
were  performed  to  verify  auto-identification,  and  the  insertion  of  the  PC  card  into  its 
interface  slot  was  tested  to  verify  card  setup  functionality. 

The  results  of  these  tests  proves  the  concept  of  the  prototype,  namely  that  an 
economic  and  rugged  sensor  interface  can  be  developed  which  will  assist  in  the 
automation  and  efficacy  of  the  field  medic’s  duties. 


2.5  Non-Invasive  Sensors 
.2.5.1  Research 

UTRS  proposed  to  integrate  two  (2)  non-invasive  sensors  into  the  CAMA  system. 
Over  the  years,  we  have  maintained  professional  relationships  with  several  medical 
product  companies,  anid  upon  commencement  of  this  STTR,  we  contacted  IV AC  Medical 
Systems,  Nellcore  Puritan  Bennett  (NPB),  and  Datascope,  Inc.  to  explore  the  options  of 
obtaining  an  electronic  thermometer  and  a  pulse  oximetery  sensor  to  integrate  into  the 
CAMA  system.  As  might  be  expected,  our  overture  was  met  with  caution,  if  not  with 
suspicion,  but  after  many  phone  conversations,  meetings,  written  correspondence,  and 
non-disclosure  agreements,  we  were  able  to  obtain  the  electronic  thermometer  apparatus, 
as  well  as  the  external  hardware  required  for  pulse  oximetery  measurements. 

2.5.2  Work  Carried  Out 

UTRS  obtained  an  electronic  temperature  sensor  from  Datascope,  Inc.  and 
associated  cabling.  In  addition  we  were  able  to  obtain  a  pulse  oximetery  sensor  from 
Datascope;  however,  this  type  of  device  requires  the  use  of  Datascope’ s  proprietary 
algorithms  as  well  as  proprietary  hardware  necessary  for  pre-processing  of  data.  We  were 
unable  to  secure  a  satisfactory  agreement  with  Datascope  for  this  Phase  I  effort  to  obtain 


the  algorithms  and  pre-processing  hardware,  therefore  we  simulated  the  pulse  oximetery 
data  and  parsed  the  information  into  the  CAMA  Vital  Signs  module. 

The  sensor’s  cables  were  truncated  and  fitted  into  a  standard  RS232  wiring 
harness  to  mate  with  a  similarly  outfitted  ending  to  the  PC  Card  trunk  cable. 

2.5.3  Results  Obtained 

The  temperature  sensor  operates  successfiilly  and  parses  the  collected  data  into  the 
CAMA  Vital  Signs  module.  As  previously  stated,  the  pulse  oximetery  sensor  parses 
simulated  data  into  the  same  module. 


2.6  Head  Mounted  Display 

2.6.1  Research 

HMD  designs  currently  use  a  number  of  display  technologies  to  provide  an  image 
to  the  user.  The  most  commonly  used  displays  in  commercially  available  systems  are  CRT 
and  LCD,  although  there  are  numerous  other  display  technologies  under  active 
development.  The  following  is  a  brief  overview  of  the  current  status  of  these  technologies 
relative  to  their  use  in  HMDs. 

2.6. 1 . 1  Cathode  Ray  Tube  (CRT) 

CRT  technology  is  one  of  the  primary  display  sources  utilized  in  visual  out-the- 
window  simulation.  The  use  of  CRT  monitor  or  projection  type  displays  provides  for  the 
high  brightness  and  resolution  required  for  high  fidelity  simulations.  In  the  area  of  HMDs, 
CRTs  currently  provide  the  highest  commercially  available  display  resolution.  Today's 
technology  provides  small  (1-1.5  inch)  CkT  displays  that  can  be  mounted  on  the  head  to 
provide  higher  brightness  and  resolution  than  other  display  technologies.  Separate  CRTs 
are  used  to  provide  an  image  that  is  projected  through  specially  designed  optics  to  provide 
an  image  to  each  eye  and  in  some  cases,  two  CRTs  are  dedicated  to  each  eye  with  one 
providing  a  lower  resolution  background  image  and  the  other  providing  a  high  resolution 
inset  that  is  located  in  the  center  of  the  field  of  view. 

2.6. 1 .2  Electro-luminescent  (EL) 

EL  technology  has  been  developed  in  the  small  (1.3  x  1.1  inches),  high  resolution 
format.  This  technology  has  applications  as  both  a  direct  image  source  and  as  a  backlight 
for  the  LCD  displays.  Small  EL  displays  are  currently  being  developed  with  a  pixel  spacing 
of  24  microns  and  a  resolution  of  1280  x  1024  with  future  plans  for  a  pixel  spacing  of  12 
microns  and  a  resolution  of  2048  x  2560.  AC  EL  displays  are  available  with  screens  up  to 
1,024  X  768  lines,  in  an  18-inch  diagonal  width,  and  with  black  layer  technology  as  a 
contrast  enhancement  process  for  commercial  applications.  This  technology  is  well  suited 
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for  harsh  military  ground  vehicles  (M1A2,  Challenger  2,  M109  Howitzer,  AGS,  etc.). 
Gray  scale  of  64  level  has  been  produced  with  up  to  100  lines  per  inch  panels.  High 
resolution  EL  display  for  2nd  generation  is  being  developed  for  the  M1A2  system 
enhancement  program  (1,316  x  480  pixel,  16:9  aspect  ration,  64  gray  levels,  and  170  lines 
per  inch  horizontally).  Small  size  full  color  EL  displays  are  in  low  rate  production  now. 

2.6. 1 .3  Ferro-Electric  Liquid  Crystal  (FLC) 

Ferro-electric  liquid  crystal  displays  are  non-emissive  displays  that  have  been 
researched  by  several  companies  in  the  past  few  years.  As  a  technology  it  has  some 
significant  improvements  over  the  mainstay  of  display  technologies,  because  its  viewing 
angle  is  significantly  wider  and  independent  of  multiplexing  ratio.  FLC  technology 
consists  of  a  thin  slab  of  FLC  material  between  a  pair  of  substrates  that  bear  electrodes. 
The  display  is  based  on  a  spatial  light  modulator  that  consists  of  an  array  of  square  pixels 
organized  in  rows  and  columns.  Each  pixel  in  the  array  can  be  electrically  turned  on,  as 
opposed  to  AMLCDs  which  must  use  three  pixels  and  mix  their  light  to  make  an 
equivalent  range  of  colors  (triads).  FLC-based  technology  as  it  relates  to  HMDs  is  a  very 
recent  development  and  is  currently  available  only  in  kit  form. 

2.6. 1 .4  Liquid  Crystal  Displays  (LCD) 

LCD  technology  has  made  great  advances  in  the  area  of  high  resolution.  Small 
(1.3  X  1,1  inches)  LCD-based  displays  are  currently  integrated  into  numerous  HMD 
designs.  Monochrome  resolution  of  640  x  480  displays  have  been  demonstrated  and  there 
are  plans  in  the  very  near  future  to  provide  1280  x  1024  and  2560  x  2048  resolution 
displays.  LCDs  are  categorized  into  two  types;  passive-matrix  (PMLCD)  and  active 
matrix  (AMLCD). 

2.6. 1 .4. 1  Passive  Matrix  Liquid  Crystal 

Currently,  most  PMLCDs  are  operated  in  the  transmissive  mode  with  backlight. 
The  backlight  consist  of  fluorescent  tubes  with  a  diffuser  for  producing  a  uniform 
luminance  over  the  display  surface.  Color  LCDs  require  more  power  than  monochrome 
displays.  To  produce  color  in  liquid-crystal  technologies,  one  of  the  substrates  has  to  have 
red-green-blue  (RGB)  striped  color  filters  on  it.  However,  even  with  their  higher  power 
requirement  over  monochrome,  the  color  LCDs  consume  less  power  than  any  of  the  other 
competing  color  emissive  display  technologies.  The  other  two  parameters  limiting  the 
application  of  PMLCDs  are  the  response  time  and  the  viewing  angle.  Recent 
developments  in  material  and  cell  construction  have  improved  contrast  ratio  and  viewing 
angle  characteristics,  and  has  resulted  in  slower  response  time  for  liquid-materials.  The 
display  size  of  this  technology  is  limited  (because  it  is  refreshed  technology  without 
memory)  by  the  contrast  ratio  and  viewing  angle  requirement  which  will  always  decrease 
with  an  increase  in  the  number  of  multiplexed  lines.  In  spite  of  these  limitations,  the  STN 
PMLCDs  still  remain  attractive  because  they  have  a  lower  cost  and  a  large  supplier  base 
compared  to  the  alternatives. 


2.6.1.4.2 


Active  Matrix  Liquid  Crystal  Displays 


AMLCD  technologies  are  not  limited  as  PMLCDs  are  by  the  dependence  of 
viewing  angle  and  contrast  ratio  on  the  number  of  multiplexed  lines.  This  limitation  is 
removed  by  adding  a  semiconductor  device,  e.g.,  a  thin-film-transistor  (TFT),  or  thin-film- 
diode  (TFD),  at  every  pixel,  which  provides  the  charge  storage  (memory).  Thus,  the 
display  panel  matrix-addressing  signals  are  applied  directly  to  the  semiconductor  device 
and  through  it  to  the  liquid-crystal,  resulting  in  higher  contrast  ratios  and  wider  viewing 
angles  for  the  AMLCDs.  The  TFT  AMLCD  technology  promises  good  visuaFelectrical 
characteristics  and  low  power,  and  has  recently  started  appearing  in  high  price  models. 
Even  with  the  improvement  that  this  technology  has  demonstrated  over  the  PMLCD 
technology,  it  still  has  some  parameters  that  need  to  be  improved  forther,  most  important 
of  which  is  the  narrow  viewing  angle  for  the  lowest  contrast  gray  levels,  which  also  results 
in  a  change  of  color  at  wide  viewing  angles.  The  response  time  and  high  temperature 
performance  also  need  to  be  improved. 

2.6. 1 .5  Microtip  Field  Emissive  Displays 

Microtip  field  emissive  display  (MFED)  technology  has  been  around  for  over  a 
decade  with  several  companies  demonstrating  impressive  prototypes  both  in  monochrome 
and  in  color  displays  with  6  inch  diagonals  (not  yet  in  HMD  form  factor).  In  addition  to 
its  response  time,  viewing  angle,  and  average  power  advantages  (compared  to  TFT  and 
AMLCD),  it  also  promises  a  lower  manufacturing  cost.  Also  attractive  is  the  prospect  of 
doing  all  of  The  logical  fimctions  with  the  same  basic  technology  on  the  substrate.  Its 
major  drawbacks  include  a  requirement  for  high  voltage  drive  circuits  (80  volts),  and  for 
new  low  voltage  phosphor  materials.  This  rivals  the  objective  of  AMLCD  developers  who 
would  like  to  do  the  line  data  shifting,  column  drivers,  and  row  multiplexing  drivers  with 

TFTs  fabricated  on  the  same  substrate  as  the  display. 

.*  . 

2.6. 1.6  Plasma 

Plasma  technology  is  currently  being  applied  to  flat  panel  displays  but  not  in  the 
sizes  that  are  required  for  HMD  applications.  DC  plasma  products  from  Japan  primarily 
dominate  plasma  display  usage  in  portable  computers  mainly  due  to  cost.  The  recent 
introduction  of  black  background  DC  plasma  technology  has  provided  the  larger  contrast 
ratio  needed  for  16  gray  levels  and  for  color.  This  technology  has  been  demonstrated  with 
up  to  125  lines  per  inch  resolution  in  the  monochrome  implementation.  AC  plasma 
displays  have  not  found  as  wide  a  usage  compared  to  the  DC  plasma  displays,  primarily 
due  to  their  high  price.  However,  recent  developments  in  AC  plasma  promise  to  achieve 
costs  competitive  with  that  of  DC  plasma.  The  AC  plasma  technology  provides  higher 
luminance  and  higher  contrast  ratios  at  lower  power,  compared  to  DC  plasma  technology. 
AC  plasma  displays  also  have  memory  which  makes  the  luminance  independent  of  the 
number  of  multiplexed  lines.  Thus,  there  is  no  limitation  on  the  panel  size  based  on 
luminance  as  there  is  with  DC  plasma  technology  and  other  refresh  technologies.  AC 
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plasnia,  panels  have  been  implemented  with  64  gray  levels.  Full  color  has  been 
demonstrated  in  both  AC  and  DC  technologies,  but  not  at  high  resolution. 

2.6. 1.7  Display  Technologies 

The  following  table  illustrates  the  latest  display  technologies,  along  with  their  pros, 
cons,  and  structural  phenomena. 


SISeLAY  TECBNOJLO<5iES 

XECHNOLOGy 

ADVANTAGES 

PROBLEM  AREAS 

PHENOMENA 

AMLCD 

Active  Matrix  Liquid  Crystal 
Display 

Quality  Image 

Full  Color 

Video  Speed 

Bright  and  Dimmable 

High  Cost 

Limited  Viewing  Angle 
Backliglit 

Twisted  Nematic  Mode  of  Liquid 

Crystal  Filter  for  Color 

FLC 

Ferro-electric  Liquid  Crystal 

Quality  Image 

Full  Color 

High  Resolution 

Low  Power 

High  Cost 

Still  unavailable 

Spatial  Light  Modulator 

External  Light  Source 

LED 

Light  Emitting  Diode 

Long  Life 

High  Efficiency  in  Color 

Small  and  Medium  Size 
Limited  Blue  Available 

Solid  State  Diode  which  Emits  Visible 
Photons  at  Junction  Transition 

ELD 

Electroluminescense  Display 
(AC  Thin  Film) 

Fast.Response  Time 

No  Flicker  or  Smear 

Wide  Viewing  Angle 

Low  Efficiency 

Phosphors  Complicate  Full 
Color  Design 

Phosphor  with  Dialectric  in  Triple 

Layer 

Existed  witli  AC  High  Electric  Field 

PDF 

Plasma  Display  Panel 
(DC  and  AC) 

Large  Size 

Bright 

Fast  Response 

Wide  Viewing 

Low  Efficiency 

Phosphors  Complicated 

Full  Color  Design 

Classical  Gas  Discharge  with  Light 
from  Positive  Column  and  Phosphors 

STNLCD 

Super  Twisted  Nematic 

Liquid  Crystal  Display 
(Passive  Matrix) 

Low  Cost 

Flexible  in  Application 
Color  (CSTNLCD) 

Slow  Response 

Small  Size 

Birefringence  with  Polarizer  and 
Analyzer 

Retarder,  Compensating  Film  Used  to 
get  White 

TNLCD 

Twisted  Matrix  Liquid 

Crystal  Display 
(Passive  Matrix) 

Low  Cost 

Simple  Construction 

.*  . 

Slow  Response 

Small  Size 

Birefringence  with  Polarizer  and 
Analyzer 

Retarder,  Compensating  Film  Used  to 
get  Wliite 

FED 

Field  Emitter  Display 
(Flat  CRT) 

Low  Cost  Expectation 

Still  in  Development 

Electrons  Emitted  from  Tips  and 
Accelerated  Similar  to  VFD 

2.6. 1.7  Cost  Drivers  For  Display  Technology 

There  are  at  least  four  factors  which  affect  cost  in  an  HMD.  These  factors 
distinguish  low  cost  display  systems  from  moderate  or  high  cost  display  systems.  These 
display  parameters  cannot  be  ignored  because  they  affect  the  overall  visual  performance 
and  quality  of  the  scene  that  the  eye  perceives.  Degradation  in  any  one  of  these  parameters 
will  impact  performance.  A  brief  discussion  of  each  is  presented  below. 


2.6.1.7.1 


Resolution 


Resolution  relates  not  only  to  the  number  of  horizontal  and  vertical  pixels 
displayed  but  it  is  also  a  function  of  lens  type,  spot  size  (electrostatic  or  electromagnetic 
focus  if  using  CRT),  bandwidth  and  contrast  (Modulation  Transfer  Function).  The  higher 
the  resolution,  the  more  the  projection  system  will  cost. 

2.6. 1.7.2  Brightness 

Brightness  is  a  function  of  the  type  of  light  source  (arc-lamp  or  CRT  based),  lens 
type  and  coating,  folded  optics,  field-of-view  and  screen  type.  If  a  high  brightness  is 
needed,  then  cost  will  increase. 

2.6. 1.7.3  Geometric  Distortion  Correction 

Distortion  Correction  is  the  ability  of  the  display  system  to  correct  for  keystoning 
and  barrel  distortion  introduced  when  projecting  oflf-axis  and/or  on  a  curved  screen. 
Depending  on  the  size  and  curvature  of  the  screen,  distortion  correction  will  increase  the 
cost  of  the  projection  system. 

2.6. 1.7.4  Field  Of- View 

The  area  projected  to  the  viewer  will  directly  affect  the  brightness,  contrast  and 
resolution.  If  higher  brightness/contrast/re  solution  and  a  large  field-of-view  is  needed 
(more  projectors),  then  cost  will  increase.  ; ; 

2.6. 1.7.5  HMD  Vendors  and  Products 

Throughout  this  effort,  UTRS  has  compiled  a  list  of  HMD  vendors  and  their 
products.  Table  2.6.1.7.5-1  illustrates  the  diversity  that  is  currently  available  and  the 
technology  that  is  being  utilized. 
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3.0  SUMMARY 


The  CAMA  system  successfully  demonstrates  the  feasibility  of  effective,  mobile, 
medical  treatment  and  display.  Under  this  six  month  effort,  we  were  able  to  research, 
develop,  and  integrate  many  diverse,  state-of-the-art  computer  and  medical  technologies 
into  a  fonctional  prototype.  The  CAMA  prototype,  although  limited  in  its  functionality, 
unquestionably  demonstrates  the  future  benefits  that  can  be  realized  in  a  battlefield  or 
commercial  environment  from  a  mobile  medical  platform. 


4.0  FUTURE  RESEARCH 

UTRS  welcomes  the  opportunity  to  further  the  capabilities  of  the  CAMA  system. 
The  following  is  a  brief  synopsis  of  the  advances  that  would  be  accomplished  under  a 
Phase  n  effort. 

4.1  CAMA  Software 

UTRS  would  complete  the  CAMA  voice  recognition  application.  This  would 
include  the  interface  and  content  to  all  referenced  modules.  The  CAMA  System  would  be 
a  comprehensive  voice-activated  medical  application,  including  robust  medical  S.O.Ps  and 
Protocol  interfaces.  We  would  utilize  a  high-end  commercial-off-the-shelf  (COTS)  VRP 
(e.g.  Dragon  Dictate  Professional  Series,  or  IBM  VoiceType3)  for  baseline  capabilities, 
and  then  modify  the  system  to  rapidly  display  select  medical  information  suitable  for  field 
use.  This  would  include  hypertexted  S.O.Ps,  voice-based  email  transmission  and  retrieval 
capabilities,  etc.  In  addition,  the  CAMA  System  would  be  adapted  for  wireless 
communication  capable  of  transmission  and  reception  in  the  field. 

By  the  end  of  1998,  Motorola  has  stated  that  it  will  have  launched  66  Irridium 
satellites  that  will'  enable  cellular  capability  anywhere  in  the  world.  (At  least  four  other 
companies,  including  Microsoft,  Hughes,  and  Loral  intend  on  launching  their  own 
satellite-based  telecommunications  network  by  the  year  2002.  The  Microsoft  endeavor 
entails  the  launching  of  840  satellites  by  itself)  The  CAMA  system,  since  it  has  cellular 
system  capabilities  via  PC  Card,  would  be  able  to  send  and  receive  vital  medical 
information  an3rwhere  in  the  world.  This  would  result  in  a  very  effective  telemedecine 
tool.  Furthermore,  updating  the  CAMA  system  would  be  as  simple  as  downloading  the 
latest  version  from  a  website. 

4.2  Electronic  Breadboard 

UTRS  would  further  the  development  of  the  EB  to  create  an  intelligent  Medical 
Computer  Enhancement  (MCE)  PC  Card  that  is  capable  of  interfacing  to  at  least  6  non- 
invasive  sensors.  The  addition  of  First  In  First  Out  (FIFO)  processors  would  enable  the 
Card  to  perform  discreet  input/output  (I/O).  The  ramifications  of  this  “intelligence” 
translates  into  the  following  functionality; 


•  The  PC  Card  would  not  operate  by  constantly  polling  for  sensor  data.  Data  thresholds 
could  be  set  with  conditional  responses  programmed  into  the  computer  for  respective 
conditions.  A  potential  scenario  would  work  as  follows;  a  patient  is  being  monitored 
via  non-invasive  sensors  integrated  into  the  CAMA  system.  The  PC  Card  is  activated 
because  the  sensors  have  surpassed  a  preset  threshold  (e.g.  heartrate  >  100).  The 
system  sends  a  message  to  a  roving  field  medic  via  wireless  communication.  A 
warning  alarm  notifies  the  medic  that  Patient  Jones  has  exceeded  a  preset  heart 
monitoring  condition.  This  capability  would  act  as  a  “force  multiplier”,  yielding  higher 
productivity  with  less  personnel. 

•  The  PC  Card  would  be  designed  with  discreet  FO  capabilities;  this  would  enable  the 
computer  to  send  and  receive  radio  frequency  (rf)  signals.  This  means  that  a  plethora 
of  automated  signal  processing  commands  would  be  available  for  the  user.  For 
example,  a  handicapped  individual  would  be  able  to  tell  the  computer  to  open  a  door, 
or  turn  on  a  light  (or  appliance)  and  the  computer  would  send  the  requisite  signal.  (Of 
course,  the  door  or  appliance  would  have  to  be  modified  with  a  receiver  that  would 
receive  the  rf  signals.) 

The  PC  Card’s  cabling  and  connections  would  be  modified  for  quick  access  and 
release.  Furthermore,  UTRS  would  research  requirements  for  advanced  automated 
manufacturing  to  produce  the  PC  Card  in  large  quantities  rather  than  by  hand. 

4.3  Head  Mounted  Display 

Throughout  the  Phase  I  effort,  UTRS  has  researched  the  current  state-of-the-art 
HMD  products  and  manufacturers.  We  are  in  a  unique  position  to  design  and  develop  a 
prototype  HMD  designed  for  medical  field  use.  UTRS  would  design  the  HMD  in-house 
using  our  computer-aided  design  (CAD)  workstations.  Next,  we  would  solicit  bids  from 
at  least  three  HMD  manufacturers  to  build  a  prototype  HMD  according  to  our 
specifications.  Lastly,  we  would  negotiate  with  the  yendors  to  obtain  the  best  product  at 
the  best  price. 
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